home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 14 / CU Amiga Magazine's Super CD-ROM 14 (1997)(EMAP Images)(GB)(Track 1 of 3)[!][issue 1997-09].iso / CUCD / Programming / AMOS / AMOSList0597 / AMOSLIST / text0249.txt < prev    next >
Encoding:
Text File  |  1997-06-01  |  2.1 KB  |  62 lines
  1. On 22-mei-97 Ben Wyatt wrote:
  2.  
  3. >The one thing which seems to be very hard to achieve in AMOS 
  4. >is full screen, multidirectional, map based scrolling 
  5. >SMOOTHLY. I would like to see this in the new AGA extension 
  6. >(or any extension) more than anything else (apart from AGA!). 
  7. >Perhaps similar to the Turbo (Plus) extension, with a Map bank 
  8. >and Tile bank, but also commands to open and scroll the view 
  9. >port... just a few examples:
  10.  
  11. >Map Screen Open n,view_width,view_height,colours,mode,block_size
  12. >   Open the screen. (block_size = 16 or 32)
  13.  
  14. >Map Offset n,x,y
  15. >   Move the view to x,y - Scroll the screen, or redraw it completely if
  16. >   it's totally off the current view.
  17.  
  18. >Map Scroll n,dx,dy
  19. >   Relatively scroll the view by dx,dy pixels.
  20.  
  21. >What do you all think? Would this be useful?
  22.  
  23. If it would really make things faster, this would be _very_ useful.
  24.  
  25. Maybe add some analytical functions, like =Map Screen, etc. (I don't know of
  26. any use for those, but you can be sure that someday, someone will need them).
  27.  
  28. Another thing: I read on this list some time ago an optimisation tip for map
  29. based games, which was to store the map as many times as there are directions
  30. you can scroll in. The advantage being, that you can then lay out the map in
  31. memory in such a way that you have only to increase the pointer to read the
  32. next tile.
  33.  
  34. So a scroll to the left would be done
  35. PTR=??? 'position on the map
  36. For Y=1 To HEIGHT
  37.   Inc PTR
  38.   TILE=Peek(PTR)
  39.   _PASTE_TILE(X,Y,TILE)
  40. Next Y
  41.  
  42. Rather than:
  43. For Y=1 To HEIGHT
  44.   TILE=Peek(_START+X+Y*WIDTH)
  45.   _PASTE_TILE(X,Y,TILE)
  46. Next Y
  47.  
  48. The optimisation bit lies in the fact that you don't have much of a
  49. calculation to determine where to read the next tile from. I don't know if it
  50. works, as I have never tried it, but it seems genuine enough.
  51.  
  52. How would you deal with such things in your proposed extension?
  53.  
  54. (I bet it is all already in AMCAF :-) )
  55.  
  56. -- 
  57. Branko Collin                                              . |. .
  58. collin@xs4all.nl                                         . . || ...
  59. http://www.xs4all.nl/~collin                          . ....||| .. ..
  60.  
  61.  
  62.